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1 SERVICE CONTROL MANAGER SECURITY MANAGER LOOKUP 

2 Technical Field 

3 The present invention relates to system administration management, and, in particular , to service 

4 control manager modules. 

5 Background 

6 Tool definition and execution in a service control manager (SCM) module may involve 

7 complicated processes, including authorizing a user to run a tool on target nodes. To ensure system 

8 security, a process for checking user authorization is needed before the user is allowed to execute the 

9 tool on the target nodes. Prior solutions include the use of a database that contains the authorized user 

n 

2 1 0 identification to run a certain tool. However, the use of the database requires a complicated database 

O 1 1 application to be installed on the system, and requires the database application to be constantly updated 

2 12 through manual input. A simple user authorization checking process is needed. 

13 Summary 

* 1 4 Role based authorization in a service control manager (SCM) module may alio w a system 

O 

W 1 5 administrator to delegate responsibility to other users by assigning tool based roles to these users on 

U 1 6 a system to provide them with full access to such system. To ensure system security, after receiving 

2 1 7 a request from a user to run a tool on a set of target nodes, an SCM security manager may need to 

1 8 check whether the user is authorized to run the tool on the target nodes in order to validate the user' s 

19 authorization. 

20 The method for validating a user' s authorization to run a tool in the SCM module by the security 

2 1 manager may include obtaining user identification (ID), a list of target nodes on which to run the tool, 

22 and tool definition from a runnable tool object created by the SCM module based on task information 

23 provided by the user and tool definition provided by a domain manager. Next, the security manager 

24 may obtain roles associated with the tool from the tool definition, and check if any of the roles are 

25 enabled. If any of the roles are enabled, the security manager may then check if the user is authorized 

26 on all of the nodes, and if the user is authorized for one of the tool' s enabled roles on all of the nodes. 

27 Only if the user is assigned with any of the tool's enabled roles on all of the target nodes, the security 
2 8 manager will report back to the SCM module indicating that the tool is runnable by the user. If the user 
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1 is not authorized on each of the nodes requested, or if the user is not authorized for any of the tool's 

2 enabled roles, the tool is not runnable by the user. 

3 Description of the Drawings 

4 The detailed description refers to the following drawings, in which like numbers refer to like 

5 elements, and in which: 

6 Figure 1 illustrates a computer network system with which the present invention may be used; 

7 Figure 2 illustrates the relationships between the user, role, node, tool and authorization objects; 
"8 Figure3 is a block diagram of an exemplary server used to implement the present invention; 

9 Figure 4 is a flow chart of a method for checking a user's authorization to run a tool in the SCM 

O 10 module by a security manager; and 

jjj 11 p%ttre-&4s-erf^^ 

g 12 recervrng-trtooi-e^^ 

m 13 Detailed Description 

^14 A service control manager (SCM) module multiplies system administration effectiveness by 

O 1 5 distributing the effects of existing tools efficiently across managed servers. The phrase "service control 

© 1 6 manager" is intended as a label only, and different labels can be used to describe modules or other 

^ 17 entities having the same or similar functions. 

1 8 In the SCM domain, the managed servers (systems) are referred to as "managed nodes" or 

1 9 simply as "nodes". SCM node groups are collections of nodes in the SCM module. They may have 

20 overlapping memberships, such that a single node may be a member of more than one group. The 

2 1 grouping mechanism may allow flexible partitioning of the SCM module so that users may use it to 

22 reflect the way nodes are already grouped in their environment. 

2 3 Figure 1 illustrates a computer network system with which the present invention may be used. 

24 The network system includes an SCM 1 1 0 running on a Central Management Server (CMS) 1 00 and 

25 one or more nodes 1 30 or node groups 1 32 managed by the SCM 1 1 0. The one or more nodes 130 

26 and node groups 132 make up an SCM cluster 140. 

27 The CMS 1 00 can be implemented with, for example, an HP-UX 1 1 .x server running the SCM 

28 110 software. The CMS 1 00 includes a memory 1 02, a secondary storage device (not shown), a 
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1 processor 1 08, an input device (not shown), a display device (not shown), and an output device (not 

2 shown). The memory 1 02 may include computer readable media, RAM or similar types of memory, 

3 and it may store one or more applications for execution by processor 108, including the SCM 1 10 

4 software. The secondary storage device may include computer readable media, a hard disk drive, 

5 floppy disk drive, CD-ROM drive, or other types of non-volatile data storage. The processor 1 08 

6 executes the SCM software and other application(s), which are stored in memory or secondary 

7 storage, or received from the Internet or other network 1 1 6. The input device may include any device 

8 for entering data into the CMS 1 00, such as a keyboard, key pad, cursor-control device, touch-screen 

9 (possibly with a stylus), or microphone. The display device may include any type of device for 
5 1 0 presenting a visual image, such as, for example, a computer monitor, flat-screen display, or display 
g 1 1 panel. The output device may include any type of device for presenting data in hard copy format, such 
3 1 2 as a printer, and other types of output devices include speakers or any device for providing data in 
5 1 3 audio form. The CMS 1 00 can possibly include multiple input devices, output devices, and display 

ili 

14 devices. 

it 

R 1 5 The CMS 1 00 itself may be required to be a managed node, so that multi-system aware 

§ 16 (MSA) tools may be invoked on the CMS. All other nodes 130 may need to be explicitly added to 

Q 17 the SCM cluster 140. 

1 8 Generally, the SCM 1 1 0 supports managing a single SCM cluster 1 40 from a single CMS 1 00. 

19 All tasks performed on the SCM cluster 140 are initiated on the CMS 100 either directly or remotely, 

20 for example, by reaching the CMS 1 00 via a web connection 114. Therefore, the workstation 1 20 at 

2 1 which a user sits only needs a web connection 1 1 4 over a network 116, such as the Internet or other 

22 type of computer network, to the CMS 1 00 in order to perform tasks on the SCM cluster 1 40. The 

23 CMS 100 preferably also includes a centralized data repository 104 for the SCM cluster 140, a web 

24 server 1 1 2 that allows web access to the SCM 1 1 0 and a depot 1 06 that includes products used in the 

25 configuring of nodes 130. A user interface may only run on the CMS 100, and no other node 130in 

26 the SCM module may execute remote tasks, access the repository 1 04, or any other SCM operations. 

27 Although the CMS 100 is depicted with various components, one skilled in the art will 

28 appreciated that this server can contain additional or different components. In addition, although 
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1 aspects of an implementation consistent with the present invention are described as being stored in 

2 memory, one skilled in the art will appreciated that these aspects can also be stored on or read from 

3 other types of computer program products or computer-readable media, such as secondary storage 

4 devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet or other 

5 network; or other forms of RAM or ROM. The computer-readable media may include instructions 

6 for controlling the CMS 100 to perform a particular method. 

7 A central part of the SCM module 1 1 0 is the ability to execute various management commands 

8 or applications on the one or more nodes simultaneously. The commands or applications may need to 

9 be encapsulated with an SCM tool, which is typically used to copy files and/or execute commands on 
O 10 the target nodes 130. The SCM tool mayrunsimplecommandssuchasbdf(l)ormount(lM), launch 
03 1 1 single system interactive applications such as System Administration Manager (SAM) or Glance, launch 
□ 1 2 multi-system aware applications such as Ignite/UX or Software Distributor (SD), or perform other 

1 3 functions. The tool may be defined using either an SCM tool definition language through command line 

14 interface (CLI) or an SCM-provided graphical user interface (GUI). 

Q 1 5 There are two general types of tools: single-system aware (SS A) tools and multi-system aware 

16 (MSA)tools. SSA tools may run on a node 130 and may only affect the operation of that node 130. 

17 To run SSA tools on multiple target nodes 1 30, the SCM module 1 1 0 may execute the tools on each 

1 8 target node 1 30. In addition to executing commands or launching applications, SSA tools may copy 

19 files from the CMS 100 to the target nodes 130. Files may only be copied from the CMS lOOtothe 

20 managed nodes 1 30 in this exemplary embodiment, not from the nodes 1 30 back to the CMS 1 00. 

2 1 MSA tools may run on a single node 1 30 but may be able to operate on multiple other nodes 

22 130. MSA tools are applications that execute on a single node but can detect and contact other nodes 

23 to accomplish their work and this contact is out ofthe control ofthe SCM module 110. Thistypeof 

24 application may need to have a list of nodes 1 30 passed as an argument at runtime. A node 1 30 where 

25 the application will execute may need to be specified at tool creation time, not at runtime. The target 

26 nodes 130 selected by the user may be passed to an MSA tool via a target environment variable that 

27 contains a target node list for the MSA tools. MSA tools may not copy files to either the manager node 

28 100 or to the target nodes 130 in this exemplary embodiment. Therefore, an execution command string 
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1 may be required for MSA tools. 

2 An SCM user may be a user that is known to the SCM module 1 10 and has some SCM 

3 related privileges and/or system management roles. An SCM role, which is an expression of intent and 

4 a collection of tools for accomplishing that intent, typically defines what the user is able to do on the 

5 associated nodes 130 or node groups 132, e.g., whether a user may run a tool on a node 130. 

6 Typically, in order to start the SCM module 1 1 0 or execute any SCM tools, the user may need to be 

7 added to the SCM module 1 1 0 and authorized either via the GUI or the command line interface (CLI). 

8 All SCM module" 110 operations may be authorized based on the user's SCM authorization 

9 configuration, and/or whether or not the user has been granted SCM trusted user privilege. 

3 1 0 The SCM user may, depending upon the roles assigned, manage SCM systems via the SCM 

S 1 1 module 1 1 0. In addition, the user may examine the SCM module log, and scan the group and role 

P 1 2 configurations. When the SCM user runs a tool, the result may be an SCM task. The SCM module 

08 1 3 110 typically assigns a task identifier for every task after it has been defined and before it is run on any 
03 . 

b' 14 target nodes 130. This identifier may be used to track the task and to look up information later about 

M 15 the task in an SCM central log. 

m 16 An SCM trusted user is an SCM user responsible for the configuration and general 

□J 1 7 administration of the SCM module 110. The trusted user is typically a manager or a supervisor of a 

1 8 group of administrators whom a company trusts, or other trusted individual. Entrusted with the highest 

1 9 authority, the trusted user may execute any system management task with all of the nodes (machines) 

20 managed by the SCM module 110. The capabilities of the trusted user include, for example, one or 

2 1 more of the following: creating or modifying a user's security profile, such as user ID or user's set of 

22 SCM authorizations; adding, modifying or deleting a node or node group; enabling or disabling roles; 

23 modifying or authorizing tools. The granting of these privileges implies a trust that the user is responsible 

24 for configuring and maintaining the overall structure of the SCM module 110. 

25 An SCM authorization model supports the notion of assigning to users the ability to run a set 

26 of tools on a set of nodes. An authorization obj ect is an association that links a user to a role on either 

27 a node or a node group. Each role may have one or more tools and each tool may belong to one or 

28 more roles. When users are given the authority to perform some limited set of functionality on one or 
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more nodes, the authorization is done based upon roles and not on tools. The role allows the sum total 

2 of functionality represented by all the tools to be divided into logical sets that correspond to the 

3 responsibilities that would be given to the various administrators. Accordingly, there are different roles 

4 that may be configured and assigned with authorization. For example, a backup administrator with a 

5 "backup" role may contain tools that perform backups, manage scheduled backups, view backup 

6 status, and other backup functions. On the other hand, a database administrator with a "database" role 

7 may have a different set of tools. When a user attempts to run a tool on a node, the user may need to 

8 be checked to determine if the user is authorized to fulfill a certain role on the node and if that role 

9 contains the tool. Once a user is assigned a role, the user may be given access to any newly created 

10 tools that are later added to the role. In the example given above, the backup administrator may be 

1 1 assigned the "backup" role for a group of systems that run a specific application. When new backup 

1 2 tools are created and added to the "backup" role, the backup administrator may immediately be given 
'fQ 1 3 access to the new tools on the systems. 

1 4 Figure 2 illustrates the relationships between the user 210, role 220, node 1 30, tool 240, and 

15 authorization 250 objects. Userobjects 210 represent users 210, role objects 220 represent roles 

1 6 220, node objects 130 represent nodes 130, tool objects 240 represent tools 240, and authorization 
P 1 7 objects 250 represent authorizations 250. However, for purposes of this application, these terms are 

1 8 used interchangeably. Each authorization object 250 links a single user obj ect 2 1 0 to a single role 

1 9 object 220 and to a single node object 1 30 (or a node group object 132). Each role object 220 may 

20 correspond to one or more tool objects 240, and each tool object 240 may correspond to one or more 

2 1 role objects 220. Each user object 2 1 0 may be assigned multiple authorizations 250, as may each role 

22 object 220 and each node object 130. For example, Role 1 may contain Tools l-N,andUser 1 may 

23 be assigned Roles 1 -M by the authorization model on Node 1 . Consequently, User 1 may run Tools 

24 1-N on Node 1 , based upon the role assigned, Role 1 . 

25 Table 1 illustrates an example of a data structure for assigning tools 240 and commands 

26 specified in the tools 240 to different roles 220. Table 2 illustrates an example of a data structure for 

27 assigning the roles 220 to different users 210. 
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Although Figure 2 shows a node authorization, a similar structure exists for a node group 132 
authorization. The SCM authorization model may be deployed by using node group 1 32 authorizations 
more often than node 1 30 authorizations. This model makes adding new nodes simpler because by 
addinganode 130 to an existing group 132, any authorizations associated with the group 132maybe 
inherited at run-time by the node 130. 

The authorization model for determining if a user may execute a tool 240 on a set of nodes 130 
may be defined by an "all or none" model. Therefore, the user 2 1 0 must have a valid authentication 
association for each target node 1 30 to execute the tool 240. If authorization does not exist for even 
one of the nodes 130, the tool execution fails. 

The SCM module 1 1 0 may also include security features to secure transactions that transmit 
across the network. All network transactions maybe digitally signed using a public or private key pair. 
The recipient of network transmissions may be assured of who the transmission came from and that the 
data was not altered in the transmission. A hostile party on the network may be able view the 
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1 transactions, but may not counterfeit or alter them. 

2 Referring to Figure 3, the CMS 100 may include a domain manager 330, a log manager 334, 

3 and a tool manager 336. The domainmanager 330 is the "brain" of SCM module 110 and may be 

4 connected to the repository 1 04 for storage of the definitions of all the objects. A security manager 

5 332, which is a subsection of the domain manager 330, typically guards the system security by checking 

6 whether the user 2 1 0 is authorized to run the tool 240 on all of the nodes 130 requested, i.e., whether 

7 the user 210 is assigned the roles 220 associated with the tool 240 on all of the nodes 130. For 

8 e xample,ifauser210requeststonmatool240ontwonodesl30,andtheuser210isorilyauthorized 

9 to run the tool on one node 1 30 but not the other, the SCM module 1 1 0 will not run the tool 240 on 

1 0 either node, due to the "all or none" authorization model. The log manager 334 may manage a log file 

1 1 and take log requests and write the requests to the SCM log file. The tool manager 336 typically 

12 validates the roles 220 associated with the tool 240. 

UO}^* Tool-execatioiuJiay^taf t with a r e que s t from - th o u s e r 24O^u^ateel-240 ^au ui imu» 

14 nodes 1 30. The request may include task information^h-asihtname of the tool to be run, the 

1 5 location of the tool, the nodes on which to^yiAe^oUmid required arguments of the tool, if any. An 

1 6 example of tool executionjs^sacfi^d^Umtsd States patent application of Lister, Sanchez, Drees, 

1 7 and Finz, entitled^ervke Control Manager Tool Execution", and filed on the same day herewith, 

18 gyftfcrr is incorporated herein by refere nce 

19 In the next step, the SCM module 1 1 0 may retrieve tool definition, node definition and user 

20 definition from the domain manager 3 30 to validate the task information received from the user 210. 

2 1 The domain manager 330, connected to the repository 104, may be contacted to provide tool definition 

22 or information about the nodes 1 30 or the user 2 1 0 whenever the clients need to look up a tool 240 

23 or to verify nodes 1 30. An example of tool definition is described in United States patent application 

24 of Lister, Sanchez, Drees, and Finz, entitled "Service Control Manager Tool Definition", and filed on 

25 the same day herewith, which is incorporated herein by reference. The validation of the task 

26 information may include checking whether the nodes requested are the managed nodes, whether the 

27 tools actually exist, and whether the required arguments of the tool are given. After the request is 

28 validated, the SCM module 1 1 0 may create a runnable tool object based on the task information and 

8 
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1 the tool definition. The runnable tool object may encapsulate the tool 240, the task information received 

2 from the user 2 1 0, and information that may be picked up from the environment, such as the user' s 

3 name. 

4 Authorizations for the SCM module 1 1 0 may be tuples, including the user 2 1 0, the role 220 

5 andthenode 130. Internally, the security manager 3 32 may store, for example, an identification of the 

6 users 2 1 0 by their UNIX login ID and the roles 220 by their (immutable) SCM role ID. For example, 

7 if U represents a user ID, R represents a role ID, and N represents a node name, the set of all 

8 authorizations for the SCM module 1 1 0 may comprise numerous discrete points tuples of the form (U, 
O 9 R, N) - in a three dimensional space. The set of all configured authorizations may be referred to as an 
5 1 0 SCM security policy. The security manager data object that stores all the data objects described by 
□ 1 1 the SCM security policy may form, for example, a Javahash table. The hash table is a common data 
jj 1 2 structure for providing fast indexing of information by providing an algorithm that computes some type 
® 1 3 of address based on a hash key. 

° 1 4 There are numerous ways of accessing the security policy of the SCM module 1 1 0, based on 

S 1 5 a request by the user 210. While numerous ways of viewing this data are provided, an algorithm for 

P 1 6 lookup may be designed for the most common scenario: validating whether a user 2 1 0 can execute a 

5=5 1 7 tool 240 on one or more nodes 1 3 0 by checking whether the user 2 1 0 is assigned any of the tool ' s 

1 8 enabled roles 220 on the nodes 1 30. 

1 9 The first step for security manager lookup may be synchronizing on a mutual exclusion mutex. 

20 Mutexes are simple lock primitives that can be used to control access to a shared resource - the 

21 security policy. The mutex is basically a synchronization object to prevent corruption of data by 

22 concurrently accessing the data with different threads. Only one thread or user process is able to 

23 manipulate the contents of the cache at one time, and only by acquiring the mutex. Other users must 

24 wait until the first user releases the mutex before the USPRS can modify the data. Accordingly, 

25 coherency of the data maintained by the security manager 332 may be preserved. There is no Java- 

26 specific synchronization on the mutex that controls access to the security policy hash table. 

27 Next, from the runnable tool object, the security manager 332 may obtain the user identification 
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1 (ID) of the user 2 1 0 on whose behalf the tool 240 is to be executed, a list of target nodes 1 3 0 on which 

2 the user 2 1 0 intends to execute the tool 240, and a tool definition that contains role information that 

3 must be extracted for the authorization lookup to complete. In order to execute the tool 240, the user 

4 210 must be authorized for at least one of the tool's enabled roles 220 on each target node 1 30 in this 

5 exemplary embodiment. Then, the tool manager 336 may check if the roles 220 are valid. 

6 Some of the roles 220 assigned to the tool 240 may be disabled, preventing the tool 240 from 

7 being executed by the user 2 10 who is authorized for the role 220 on the target node 130. Therefore, 

8 the security manager 332 may need to check that not all roles 220 associated with the tool 240 are 

9 disabled. 

f=S 

§ 1 0 Next, the security manager 332 may obtain the user's authorized roles 220 on each target node 

Oil 130 from the hash table, referred to as MxNodeRolelDHash, using the user ID as the hash key. This 

P 1 2 may be done by accessing three dimensional data on the user access, resulting in information that 

f§ 13 describes the roles 220 for which the user 210 is authorized on one or more nodes 130, i.e., the user's 

1 4 authorized roles 220. The hash table may be indexed by node name, and the data stored in the hash 

15 table, on a per node basis, may be a vector ofthe user's authorized roles 220 on the node 130. Vector 
5} 1 6 is a Java term, and may be referred to as a collection of data. 

1 7 If, however, an attempt to obtain the user's authorized roles 220 from the hash table results in 

1 8 nothing being returned, then the user 2 1 0 has no authorizations in the security policy, and the user 2 1 0 

19 cannot run any tools 240 in the SCM environment. 

20 The authorization lookup may involve matching two sets of roles 220. The first set of roles 220 

2 1 is the vector of (enabled) roles 220 assigned to the tool 240. The second set of roles 220 is a vector 

22 of all roles 220 (enabled or not) the user 2 1 0 is authorized on the current node 130. The security 

23 manager 332 typically iterates through the vector ofthe tool's enabled roles 220, and checks if the user 

24 210 has been authorized for one of these roles 220 on the node 1 30. If the intersection ofthe vector 

25 (a set) ofthe tool' s enabled roles 220 and the vector (another set) of the user' s authorized roles 220 

26 for the current node 1 30 is not the empty set, then there may exist an authorization in the security policy 

27 that allows the user 2 1 0 to execute the tool 240 on the current node 130. If the intersection ofthe two 
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1 role vectors is an empty set, then authorization lookup fails, and the user 2 1 0 cannot run the tool 240. 

2 In summary, the authorization lookup effectively leverages two of the collections provided by, 

3 for example, the Java language, hash tables and vectors, to allow a novel way of accessing a 

4 complicated space of data. The three dimensional programming data is easily accessed and traversed 

5 in an intuitive, and problem domain-specific manner, because of the way it is maintained in the primary 

6 hash table. The elements stored and manipulated in this primary hash table are again hash tables, 

7 referred to as MxNodeRolelDHash objects. There may be one of these MxNodeRolelDHash objects 

8 foreachnode 130 on which an SCM user 210 is authorized arole 220. Given that the most common 
n 9 use of this lookup mechanism is for a scenario where the user ID may be considered constant, one 

5 1 0 dimension of data complexity is removed rapidly by indexing into the primary hash table by the user 

i.y 

Q 1 1 name. The resulting object, referred to as MxNodeRolelDHash, may map the user' s authorized roles 

P 12 220 to nodes 130 for which those roles 220 apply. Then the lookup may be a matter of determining 

S 1 3 if there is at least one role 220 that is common to the tool 5 s enabled roles 220 and the user' s authorized 

14 roles 220, for each target node 130. 

S 1 5 Figure 4 is a flow chart of a method for checking a user' s authorization to run a tool 240 in the 

2 1 6 SCM module 1 1 0 by a security manager 332. This method may be implemented, for example, in 

^* 1 7 software modules for execution by processor 1 08 . The first step may be synchronizing on the mutual 

1 8 exclusion (MUTEX), step 402. Next, the security manger 332 may obtain user identification (ID), a 

1 9 list of the target nodes 1 30, and the tool definition from the runnable tool object created by the SCM 

20 module 1 1 0 based on the task information and the tool definition, steps 404, 406, 408. The tool 

2 1 definition may indicate the roles 220 assigned, typically by the trusted user, to run the tool 240, step 

22 410. The roles 220 may need to be validated by the tool manager 3 36, step 4 12. Next, the security 

23 manager 332 may execute a loop to check the user's authorization to run the tool 240 on the target 

24 nodes 130. Ifall roles 220 are disabled, step 4 14, the tool 240 may be determined as not runnable at 

25 all, step 424. Conversely, if not all roles 220 are disabled, for every node 130 in the list of target 

26 nodes, the security manager 332 may check if the user 2 1 0 is assigned an authorized role 220 on the 

27 node 130, step 416. If the user is authorized, for each authorized target node 130, the security 

28 manager 332 may obtain the user's authorized roles 220 for the node 130, step 418. 
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1 Next, for each tool's enabled role 220, the security manager 332 may check if the user 2 1 0 

2 is authorized for at least one of the tool's enabled roles 220 on that node 1 30, step 420. If the 

3 intersection of the vector of the tool's enabled roles 220 and the vector of the user's authorized roles 

4 220 for the node 1 30 is not the empty set, then there may exist an authorization that allows the user 2 1 0 

5 to execute the tool 240 on that node 1 30. Only if the user 2 10 is assigned with one of the tool's 

6 enabled roles 220 on all of the target nodes 130, the tool 240 is runnable by the user 2 1 0, step 426. 

7 If the user 2 1 0 is not authorized on each of the nodes 1 30 in the target node list, or if the user 2 1 0 is 

8 not authorized for any of the tool's enabled roles 220, the tool 240 is not runnable by the user 2 1 0, step 

9 424. 

3 1 0 While the present invention has been described in connection with an exemplary embodiment, 

§ 1 1 . it will be understood that many modifications will be readily apparent to those skilled in the art, and this 

1\7 12 application is intended to cover any variations thereof. 
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